FBL 与 APP 为何要有各自的中断向量表？

在嵌入式开发中，尤其是涉及固件升级（如通过 IAP，In-Application Programming）的系统中，我们常常会看到两个独立的程序：FBL（First Boot Loader） 和 APP（Application）。一个常见的问题是：

为什么 FBL 和 APP 需要各自拥有独立的中断向量表？不能共用吗？

答案是：不能，而且必须分开。本文将深入解析其背后的设计原理。

1. FBL 与 APP：本质是两个独立程序

尽管 FBL（一级引导程序）和 APP（主应用程序）运行在同一块 MCU 上，但从程序结构和生命周期来看，它们是两个完全独立的可执行映像（Image）。

由于两者是分别编译、链接并烧录到不同 Flash 区域的程序，因此它们在编译期就各自生成了独立的中断向量表。

中断向量表（Interrupt Vector Table, IVT）是 Cortex-M 系列处理器的关键数据结构，位于程序映像的起始位置（通常是 0x0000_0000 或重映射后的地址），包含：

处理器在发生中断或异常时，会根据中断号从向量表中查找对应的处理函数地址并跳转执行。

✅ 因此，每个可独立运行的程序都必须拥有自己的中断向量表。

FBL 和 APP 通常位于 Flash 的不同区域：

当 CPU 跳转到 APP 运行时，必须将中断向量表的基地址重映射到 APP 的起始位置。否则，中断发生时仍会跳转到 FBL 的中断服务程序，导致逻辑混乱甚至系统崩溃。

// 在 APP 中启动前重定位中断向量表
SCB->VTOR = FLASH_BASE + APP_VECTOR_TABLE_OFFSET;

🔧 VTOR（Vector Table Offset Register）寄存器允许我们动态设置向量表的基地址。

FBL 的设计原则是“最小化”：
为了保证稳定性和兼容性，FBL 通常只使用极少数外设（如 USART、GPIO、Flash 控制器），因此其中断向量表中只包含必要的中断（如 USART_RX、SysTick），其余外设中断为空或指向默认处理函数。
APP 则功能复杂：
可能使用大量外设（TIM、ADC、I2C、EXTI、DMA 等），每个外设都可能触发中断，因此需要一个完整、详细的中断向量表。

如果共用 FBL 的向量表，APP 的中断将无法被正确响应。

FBL 和 APP 的职责分离是系统安全的基础：

共享中断向量表会引入不必要的耦合，一旦 APP 出错修改了向量表，可能导致系统无法再次进入 FBL 进行固件恢复。

在实际项目中，通常采用以下策略：

步骤	操作
1	FBL 编译时生成自己的向量表，位于 `0x0800_0000`
2	APP 编译时也生成向量表，但链接脚本将其定位到自身起始地址（如 `0x0800_4000`）
3	APP 启动后，通过 `SCB->VTOR = APP_BASE` 重定位向量表
4	FBL 退出前关闭所有不必要的中断，避免干扰 APP

📌 提示：使用 STM32 的 AIRCR 寄存器或启动文件 .sct 链接脚本时，需明确设置向量表偏移。

原因	说明
✅ 独立程序	FBL 与 APP 是两个独立编译、运行的程序，必须各自拥有向量表
✅ 地址不同	运行地址不同，需通过 VTOR 重定位，无法共用同一物理表
✅ 功能差异	FBL 最小化，APP 功能丰富，中断需求完全不同
✅ 安全解耦	避免相互干扰，保证系统可恢复性和稳定性

结论：FBL 与 APP 的中断向量表不仅“可以分开”，而且“必须分开”。这是嵌入式系统中实现可靠固件升级和模块化设计的基础。

理解中断向量表的管理机制，是掌握嵌入式系统底层设计的关键一步。